home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / doc / url_spec.txt < prev    next >
Text File  |  1993-11-25  |  54KB  |  1,277 lines

  1. Uniform Resource Locators (URL)                 Tim Berners-Lee
  2. Internet Draft                                             CERN
  3. Expires May 1994                                   October 1993
  4.  
  5.  
  6.                   Uniform Resource Locators (URL)
  7.                 
  8.              A Unifying Syntax for the Expression of
  9.           Names and addresses of Objects on the Network
  10.  
  11.  
  12. Status of this memo
  13.  
  14.    This document is an Internet Draft. Internet Drafts are working
  15.    documents of the Internet Engineering Task Force (IETF), its Areas,
  16.    and its Working Groups.  Note that other groups may also distribute
  17.    working documents as Internet Drafts.
  18.    
  19.    Internet Drafts are working documents valid for a maximum of six
  20.    months. Internet Drafts may be updated, replaced, or obsoleted by
  21.    other documents at any time.  It is not appropriate to use Internet
  22.    Drafts as reference material or to cite them other than as a
  23.    "working draft" or "work in progress".
  24.    
  25.    Distribution of this document is unlimited.  Please send comments
  26.    to the author as timbl@info.cern.ch. or to the discussion list
  27.    ietf-url@merit.edu.
  28.    
  29. Abstract
  30.  
  31.    Many protocols and systems for document search and retrieval are
  32.    currently in use, and many more protocols or refinements of
  33.    existing protocols are to be expected in a field whose expansion is
  34.    explosive.
  35.    
  36.    These systems are aiming to achieve global search and readership of
  37.    documents across differing computing platforms, and despite a
  38.    plethora of protocols and data formats.   As protocols evolve,
  39.    gateways can allow global access to remain possible. As data
  40.    formats evolve, format conversion programs can preserve global
  41.    access. There is one area, however, in which it is impractical to
  42.    make conversions, and that is in the names and addresses used to
  43.    identify objects.  This is because names and addresses of objects
  44.    are passed on in so many ways, from the backs of envelopes to
  45.    hypertext objects, and may have a long life.
  46.    
  47.    A common feature of almost all the data models of past and proposed
  48.    systems is something which can be mapped onto a concept of "object"
  49.    and some kind of name, address, or identifier for that object.  One
  50.    can therefore define a set of name spaces in which these objects
  51.    can be said to exist.
  52.    
  53.    Practical systems need to access and mix objects which are part of
  54.  
  55.  
  56.  
  57. Berners-Lee                                                          1
  58.  
  59. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  60.  
  61.    Practical systems need to access and mix objects which are part of
  62.    different existing and proposed systems.
  63.    
  64.    This paper discusses the requirements on a universal syntax which
  65.    can be used to encapsulate a name in any registered name space.
  66.    This will allow names in different spaces to be treated in a common
  67.    way, even though names in different spaces have differing
  68.    characteristics, as do the objects to which they refer
  69.    
  70.    The universal syntax to objects available using existing protocols,
  71.    and may be extended with technology.  It makes a recommendation for
  72.    a generic syntax, and for specific forms for "Uniform Resource
  73.    Locators" (URLs)of objects accessible using existing Internet
  74.    protocols.
  75.    
  76.    The syntax has been in widespread use by World-Wide Web software
  77.    since 1990.
  78.    
  79. Terms
  80.  
  81.    The objects on the network which are to be named and addressed
  82.    include typically objects which can be retrieved, and objects which
  83.    can be searched.  There is a great variety of other objects which
  84.    may support other operations. We imply nothing about the contents
  85.    of objects in this document. Whereas human-readable documents are
  86.    currently the center of interest of the field, we envisage all
  87.    aspects discussed in this paper applying to generalized objects
  88.    when systems to handle them become available. The "object" is the
  89.    unit of reference and need not correspond to any unit of storage.
  90.    We refer to objects which can be searched as "indexes".  We
  91.    emphasize that this is the abstract view of the client, and these
  92.    objects need not correspond to physical files on computers. We
  93.    refer to the person who does the retrieval or searching as the
  94.    user.
  95.    
  96.    Within this document, we use the terms "name" very generally for a
  97.    string of characters describing an object,  whatever its
  98.    combination of properties mentioned below.  (The term usually has a
  99.    narrower meaning but we needed some term for the universal set.).
  100.    This uniform syntax applied to a generic name is known as a Uniform
  101.    Resource Identifier (URI). The term "address" is reserved for an
  102.    string which specifies a more or less physical location.  The term
  103.    "locator" refers to a URL as here defined.  URIs which have a
  104.    greater persistence than URLs are referred to as URNs.
  105.    
  106. Characteristics
  107.  
  108.    This section characteristics of various naming schemes,
  109.    requirements which some ofexisting schemes meet, and requirements
  110.    for the URL scheme itself. URLs, as an introduction of and
  111.    background for the Recommendations section.
  112.    
  113.   USES OF NAMES AND ADDRESSES
  114.  
  115. Berners-Lee                                                          2
  116.  
  117. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  118.  
  119.   
  120.    A name allows a user, with the help of a "client" program, to
  121.    retrieve or operate on objects via a "server" program.  A name may
  122.    be passed for example:
  123.    
  124.       In communication of any form between two people, to refer to a
  125.       document, or part of a document;
  126.       
  127.       As part of the description of a link associated with a hypertext
  128.       document;
  129.       
  130.       As part of the result of searching an index.
  131.       
  132.    Some typical requirements on a name which are met to a varying
  133.    degree by various schemes are for example that the name is
  134.    
  135.   Persistent              A given name will remain valid as long as it
  136.                          is needed;
  137.                          
  138.   Extensible              A given naming syntax will remain valid
  139.                          through the introduction of new protocols and
  140.                          directory technologies;
  141.                          
  142.   Resolvable              A name will contain enough information to
  143.                          allow the document or index to which it
  144.                          refers to be accessed, perhaps via resolution
  145.                          into an intermediate, more physical, name.
  146.                          
  147.   Unique                  Each object can only have one such name.
  148.                          The fact that two such names are different
  149.                          implies that the objects to which they refer
  150.                          are different (in some way).
  151.                          
  152.   Unambiguous             The fact that two names are identical
  153.                          implies that the objects named are the same
  154.                          (in some way).
  155.                          
  156.    The syntax discussed is the syntax of one name, be it a lasting
  157.    name or a physical address.  When a directory server or hypertext
  158.    link contains a set of alternative names, then that is beyond the
  159.    scope of this syntax.  Similarly, a syntax for describing a
  160.    compound object is outside the scope of this syntax.  The specific
  161.    locator name spaces (defined under the umbrella of the general
  162.    syntax) each meet the requirements above to a greater or lesser
  163.    extent.
  164.    
  165.   CURRENT PRACTICE
  166.   
  167.    Current protocols use many different standards for names. For some
  168.    protocols, such as ISO-10163 Search and Retrieve protocol[16], the
  169.    names returned in a search are only valid during the session. For
  170.    others, such as FTP[9], they are lasting names which may be used
  171.  
  172.  
  173. Berners-Lee                                                          3
  174.  
  175. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  176.  
  177.    for object retrieval at a later time.  Typically, however, they are
  178.    not long-lasting names which are independent of the location of the
  179.    object. Such names may be provided using directory servers such as
  180.    x.500. They will refer to the registration, however formal or
  181.    informal, of a object with a particular organisation or person.
  182.    Both hypertext and  manual references rely on long- lasting names.
  183.    Current names are basically location specifiers (addresses). These
  184.    may be known as Uniform Resource Locators (URLs). They give the
  185.    necessary parts of an address for a reader to access an information
  186.    provider using the given protocol, and ask for the object required.
  187.    Examples of names used by various protocols include
  188.    
  189.     File Transfer Protocol (Postel 1985):
  190.     
  191.       Host name or IP-address
  192.       
  193.       [TCP port]
  194.       
  195.       [user name, password]
  196.       
  197.       Filename
  198.       
  199.    W.A.I.S. (Kahle 1990)
  200.    
  201.       Host name or IP-address
  202.       
  203.       [TCP port]
  204.       
  205.       local document id
  206.       
  207.     Gopher (Alberti 1991)
  208.     
  209.       Host name or IP-address
  210.       
  211.       [TCP port]
  212.       
  213.       database name
  214.       
  215.       selector string
  216.       
  217.     HTTP (Berners-Lee 1991)
  218.     
  219.       Host name or IP-address
  220.       
  221.       [TCP port]
  222.       
  223.       local object id
  224.       
  225.     NNTP (Kantor 1986) group
  226.     
  227.       Group name
  228.       
  229.  
  230.  
  231. Berners-Lee                                                          4
  232.  
  233. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  234.  
  235.       NNTP article
  236.       
  237.       Host name
  238.       
  239.       unique message identifier
  240.       
  241.     Prospero links (Neuman 1992)
  242.     
  243.    Host name or IP address
  244.    
  245.       [UDP port]
  246.       
  247.        Host specific object name
  248.       
  249.       [version]
  250.       
  251.       [identifier]*
  252.       
  253.     x.500 distinguished name
  254.     
  255.       Country
  256.       
  257.       Organisation
  258.       
  259.       Organisational unit
  260.       
  261.       Person
  262.       
  263.       Local object identifier
  264.       
  265.    Other systems with their own naming schemes include BITNET
  266.    "LISTSERV" application, FTAM file retrieval, SQLnetTM remote
  267.    database search, proprietary  distributed file systems, etc.
  268.    Conventional syntax for writing these addresses involve various
  269.    forms of punctuation to separate these parts.  This sometimes,  but
  270.    not always, allows the naming scheme to be deduced from the
  271.    punctuation. For example, a name of the form
  272.    xxx.yyy.zz.edu:/pub.aa.bb.cc often implies anonymous FTP access.
  273.    However, there is no well-defined algorithm for parsing an
  274.    arbitrary name, as there is no common syntax.
  275.    
  276.   EXPANDABILITY
  277.   
  278.    There will necessarily be a phase during which lasting names will
  279.    become more  common, as the deployment of directory services
  280.    increases to the point where  every user has direct or indirect
  281.    access to one.  Even then, however, one can envisage more than one
  282.    competing directory system, and cases in which physical  names are
  283.    still required.  A directory service takes a lasting name and
  284.    reduces it  to a physical address (or set of addresses) which,
  285.    though less useful for lasting reference, is the only way to
  286.    actually retrieve the object. An addressing syntax is required
  287.    which will be able to encompass existing  physical address spaces,
  288.  
  289. Berners-Lee                                                          5
  290.  
  291. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  292.  
  293.    and be extendible to any future protocols.  This  requires that it
  294.    contain an identifier for the protocol in use. The format of the
  295.    rest  of the address will necessarily depend to a certain extent on
  296.    the protocol.
  297.    
  298.   RELEVANCE
  299.   
  300.    The life of a name is limited by any information contained within
  301.    it which may  become prematurely invalid. It is therefore necessary
  302.    to limit the contents of a name to the information required for the
  303.    operations above.  Other extraneous information about the object
  304.    (its size, data format, authorisation details, etc.) may in general
  305.    change with time and should not be part of the name.  One might
  306.    expect such information to be part of the "header" of a object, and
  307.    for protocols to allow the header information to be retrieved
  308.    independently of the objects themselves.  Any physical address may
  309.    be subject to change with time: hence we encourage the move to
  310.    lasting names and directory services.
  311.    
  312.   UNIQUENESS
  313.   
  314.    Clearly one requires unambiguous names in the sense that one name
  315.    should refer to only one logical object. This is the case with all
  316.    the addressing schemes in use, whether they are directory systems
  317.    or physical addresses. (The internet addresses all rely on the
  318.    domain name (Mockapetris 1987) of the host to achieve this).
  319.    However, given that names can be translated, many apparently
  320.    different names  may lead to the same object. Any object may
  321.    therefore be referred to by many  names. One needs to be able to
  322.    know whether two objects, retrieved through  different paths, are
  323.    in fact the same object.  It is suggested that each object have a
  324.    unique "official" name. This name could be stored in the object in
  325.    some representations, or stored in a database  accessible to the
  326.    server, for example.  Any references within that object should be
  327.    parsed in the context of the official name.  In the presence of a
  328.    directory service, the official name will normally be the
  329.    registered name of the object. However, a name in any scheme will
  330.    do, so long as it is completely specified. On systems which do not
  331.    allow the name to be stored (such as anonymous FTP archive sites),
  332.    a possible ambiguity will always exist as to whether two similarly
  333.    named objects are in fact the same.  Note that Internet newsgroup
  334.    names are unique world-wide, and news articles carry a unique
  335.    message id. In most other cases, however, there is no guarantee
  336.    that dereferencing a URL will work, or that if it does the object
  337.    it refers to will in fact be the object intended.  URLs such as FTP
  338.    addresses are transient in that files may be moved and even
  339.    replaced by different files of the same name.  This disorganisation
  340.    may be limited by good server management, but a naming scheme which
  341.    is independent also of internet host name is obviously preferable.
  342.    
  343.   READABILITY BY PEOPLE
  344.   
  345.  
  346.  
  347. Berners-Lee                                                          6
  348.  
  349. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  350.  
  351.    This requirement has been put forward by several people (Clifford
  352.    Lynch, Douglas Engelbart among others), and disputed by others.
  353.    The author's view is that it will be a while before technology and
  354.    standardisation have reached the point at which names and addresses
  355.    will be hidden from human beings. As long as they must be written
  356.    on the backs of envelopes and "cut and pasted" between workstation
  357.    windows, there is a strong need for names to be
  358.    
  359.       Short
  360.       
  361.        Composed of printable (preferably non-white) characters
  362.       
  363.       To a certain extent, understadable by a human being.
  364.       
  365.   STRUCTURE OF NAMES AND ADDRESSES
  366.   
  367.    A physical address is required in order for:
  368.    
  369.       The user's program to contact the server;
  370.       
  371.       The server to perform the operation (e.g. search and index,
  372.       retrieve a object,  or look up the name) and return a result;
  373.       
  374.       The user's program to locate an individual position or element
  375.       within a returned object.
  376.       
  377.    This suggests that a name be structured, such that the parts
  378.    necessary for these  three operations be separate and only used by
  379.    those system elements which need  those parts. This corresponds to
  380.    the basic principle of information hiding.  In fact,  four parts
  381.    are necessary, including the indicator of the naming scheme to be
  382.    used:
  383.    
  384.       The naming scheme: a registered identifier for the protocol.
  385.       
  386.       The name of a suitable server. The format of this part must be
  387.       well defined. It will depend on the lower-layer protocols in
  388.       use.  Systems which use widely distributed information, such as
  389.       x.500 and NNTP, do not need this part as each client generally
  390.       contacts his nearest server (or a particular server).
  391.       
  392.       Information to be passed to the server. This may be private to
  393.       the server, as all names may be generated and used by the same
  394.       server. This part of the name should be opaque to the client.
  395.       
  396.       Information to be used by the application once the object has
  397.       been retrieved. This part is private to the application (or,
  398.       more strictly, the data format) and so cannot be defined here.
  399.       
  400.    Both lasting names and physical addresses often share a
  401.    hierarchical structure. This follows often from the organisation of
  402.    the system. From the naming point of view, it has the advantage
  403.    that a reference in one object to another object need not include
  404.  
  405. Berners-Lee                                                          7
  406.  
  407. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  408.  
  409.    that part of the structure which is common to both names.
  410.    
  411.   CHOICES FOR A UNIVERSAL SYNTAX
  412.   
  413.    The requirements above leave little room for choice save for the
  414.    order and punctuation of the elements of an address.  It is only
  415.    reasonable for the order of writing of the parts to be consistently
  416.    from left to right (or right to left) with increasing specificity.
  417.    Punctuation schemes fall into two categories (Huitema 1991): tagged
  418.    schemes in which field are given names, and fields which use
  419.    special characters and field order. The latter tend to be more
  420.    compact schemes.
  421.    
  422.  
  423.         protocol: aftp host: xxx.yyy.edu path:
  424.  
  425.         /pub/doc/README
  426.  
  427.         PR=aftp; H=xx.yy.edu; PA=/pub/doc/README;
  428.  
  429.         PR:aftp/xx.yy.edu/pub/doc/README
  430.  
  431.         /aftp/xx.yy.edu/pub/doc/README
  432.  
  433.    Fig 1. Some alternative tagged and untagged representations
  434.    
  435.    The choice of special symbols for punctuation tends to be a matter
  436.    of taste. It is easier to read  addresses whose symbols correspond
  437.    to those of one's favourite operating system. A variety of symbols
  438.    is needed so that when a name is abbreviated it is possible to tell
  439.    which parts have been omitted.
  440.    
  441.    The  recommendation below uses special characters in order to
  442.    achieve a compact name, and uses where possible punctuation symbols
  443.    established in the internet or unix community.
  444.    
  445.    The choice of escape character for introducing representations of
  446.    non-allowed characters also tends to be a matter of taste. An ANSI
  447.    standard exists in the C language, using the back-slash character
  448.    "\". The use of this character on unix command lines, however, can
  449.    be a problem as it is interpreted by many shell programs, and would
  450.    have itself to be escaped.
  451.    
  452.    There is a conflict between the need to be able to represent many
  453.    characters including spaces within a URL directly, and the need to
  454.    be able to use a URL in environments which have limited character
  455.    sets or in which certain characters are prone to corruption. This
  456.    conflict has been resolved by use of an hexadecimal escaping method
  457.    which may be applied to any characters forbidden in a given
  458.    context. When URLs are moved between contexts, the set of
  459.    characters escaped may be enlarged or reduced unambiguously.
  460.    
  461.  
  462.  
  463. Berners-Lee                                                          8
  464.  
  465. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  466.  
  467.    The use of multiple white space characters is discouraged  in URLs
  468.    to be printed or sent by electronic mail.  This is because of the
  469.    frequent introduction of extraneous white space when lines are
  470.    wrapped by systems such as mail, or sheer necessity of narrow
  471.    column width, and because of the  inter-conversion of various forms
  472.    of white space which occurs during character code conversion and
  473.    the transfer of text between applications.
  474.    
  475. Recommendations
  476.  
  477.    This section describes the syntax for "Uniform Resource Locators"
  478.    (URLs): that is, basically physical addresses of objects which are
  479.    retrievable using protocols already deployed on the net.  The
  480.    generic syntax provides a framework for new schemes for names to be
  481.    resolved using as yet undefined protocols.
  482.    
  483.    The syntax is described in two parts. Firstly, we give the syntax
  484.    rules of a completely specified name; secondly, we give the rules
  485.    under which parts of the name may be omitted in a well-defined
  486.    context.
  487.    
  488.   FULL FORM
  489.   
  490.    A complete URL consists of a naming scheme specifier followed by a
  491.    string whose format is a function of the naming scheme. For
  492.    locators of information on the internet, a common syntax is used
  493.    for the  IP address part. A BNF description of the URL syntax is
  494.    given in an a later section. The components are as follows.
  495.    
  496.     Fragment-id
  497.     
  498.    This represents a part of, fragment of, or a sub-function within,
  499.    an object or object. Its syntax and semantics are defined by the
  500.    application responsible for the object, or the specification of the
  501.    content type of the object. The only definition here is of the
  502.    allowed characters by which it may be represented in a URL.
  503.    
  504.    The fragment-id follows the URL of the whole object from which it
  505.    is separated by a hash sign (#).  If the fragment-id is void, the
  506.    hash sign may be omitted: A void fragment-id with or without the
  507.    hash sign means that the URL refers to the whole object.
  508.    
  509.    While this hook is allowed for identification of fragments, the
  510.    question of addressing of parts of objects, or of the grouping of
  511.    objects and relationship between contined and containing objects,
  512.    is not addressed by this object.
  513.    
  514.    This object does not address the question of objects which are
  515.    different versions of a "living" object, nor of expressing the
  516.    relationships between different versions and the living object.
  517.    
  518.   SCHEME
  519.   
  520.  
  521. Berners-Lee                                                          9
  522.  
  523. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  524.  
  525.    Within the URL of a object, the first element is the name of the
  526.    scheme, separated from the rest of the object by a colon. The rest
  527.    of the URL follows the colon in a format depending on the scheme.
  528.    
  529.     Internet protocol parts
  530.     
  531.    Those schemes which refer to internet protocols have a common
  532.    syntax for the rest of the object name. This starts with a double
  533.    slash "//" to indicate its presence, and continues until the
  534.    following slash "/".  Within that section are
  535.    
  536.   An optional user name,
  537.                           if this must be quoted to the server,
  538.                          followed by  a commercial at sign "@".  (Use
  539.                          of this field is discouraged. Provision of
  540.                          encoding a password after the user name,
  541.                          delimited by a colon, could  be made but
  542.                          obviously is only useful when the password is
  543.                          public, in  which case it should not be
  544.                          necessary, so that is also discouraged.)
  545.                          
  546.   The internet domain name
  547.                           of the host in RFC1037 format (or,
  548.                          optionally and less advisably, the IP address
  549.                          as a set of four decimal digits)
  550.                          
  551.   The port number,        if it is not the default number for the
  552.                          protocol, is given in decimal notation after
  553.                          a colon.
  554.                          
  555.   Path                    The rest of the locator is known as the
  556.                          "path". It may define details of how the
  557.                          client should communicate with the server,
  558.                          including information to be passed
  559.                          transparently to the server without any
  560.                          processing by the client.
  561.                          
  562.    The path is interpreted in a manner dependent on the protocol being
  563.    used. However, when it contains slashes, these must imply a
  564.    hierarchical structure.
  565.    
  566.   PARTIAL FORM
  567.   
  568.    In a certain limited set of cases, generally within a certain
  569.    application, it may be useful to pass only a section of the URL.
  570.    Within a object whose URL is well defined, the URL of another
  571.    object may be given in abbreviated form, where parts of the two
  572.    URLs are the same. This allows objects within a group to refer to
  573.    each other without requiring the space for a complete reference,
  574.    and it incidentally allows the group of objects  to be moved
  575.    without changing any references. This is not discussed in detail
  576.    here, it is only mentioned so that the characters required by the
  577.    technique be reserved for that purpose.  It must be emphasised that
  578.  
  579. Berners-Lee                                                          10
  580.  
  581. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  582.  
  583.    when a reference is passed in anything other than a well controlled
  584.    context, the full form must always be used.
  585.    
  586.    The partial form relies on a property of the URL syntax that
  587.    certain characters ("/") and certain path elements ("..", ".") have
  588.    a significance reserved for representing a hierarchical space, and
  589.    must be recognised as such by both clients and servers.
  590.    
  591.    A partial form can be distinguished from a full form in that a full
  592.    form must have a colon and that colon must occur before any slash
  593.    characters.
  594.    
  595.    The rules for the use of a partial name are:
  596.    
  597.       If the scheme parts  are different, the whole absolute locator
  598.       must be given. Otherwise, the scheme is omitted, and:
  599.       
  600.       If the host and/or port parts are the different, the host, port
  601.       name and all the rest of the locator must be given.
  602.       
  603.       If the access and host parts are the same, then the path may be
  604.       given in absolute (fully qualified) or relative form. Within the
  605.       path:
  606.       
  607.       If a leading slash is present, the path is absolute. Otherwise,
  608.       a relative path is interpreted as follows:
  609.       
  610.       The last part of the path of the context locator (anything
  611.       following the rightmost slash) is removed, and the given partial
  612.       URL appended in its place.
  613.       
  614.       Within the result,  all occurrences of "/xxx/.."  or "/." are
  615.       recursively removed, where xxx, ".." and "." are complete path
  616.       elements.
  617.       
  618.    Note:  If a path of the context locator end in slash, partial URLs
  619.    will be treated differently to their treatment with respect to the
  620.    same path without a slash.   Using a trailing slash on a directory
  621.    name is not therefore recommended.  The signifcance of a trailing
  622.    slash may be considered as that of the locator of a file with void
  623.    name within that  directory.
  624.    
  625.   ENCODING PROHIBITED CHARACTERS
  626.   
  627.    When a system uses a local addressing scheme, it is useful to
  628.    provide a mapping from local addresses into URLs so that references
  629.    to objects within the addressing scheme may be referred to
  630.    globally, and possibly accessed through gateway servers.
  631.    
  632.    Any mapping scheme may be defined provided it is unambiguous,
  633.    reversible, and provides valid URLs. It is recommended that where
  634.    hierarchical aspects to the local naming scheme exist, they be
  635.  
  636.  
  637. Berners-Lee                                                          11
  638.  
  639. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  640.  
  641.    mapped onto the hierarchical URL path syntax in order to allow the
  642.    partial form to be used.
  643.    
  644.    The following encoding method shall be used for mapping WAIS, FTP,
  645.    Prospero and Gopher addresses onto URLs. Where the local naming
  646.    scheme uses ASCII characters which are not allowed in the URL,
  647.    these may be represented in the URL by a percent sign "%" followed
  648.    by two hexadecimal digits (0-9, A-F) giving the ISO Latin 1 code
  649.    for that character.  Character codes other than those allowed by
  650.    the syntax shall not be used in a URL.
  651.    
  652.    The same encoding method may be used for encoding characters whose
  653.    use, although technically allowed in a URL, would be unwise due to
  654.    problems of corruption by imperfect gateways or misrepresentation
  655.    due to the use of variant character sets, or which would simply be
  656.    awkward in a given environment.  As a % sign always indicates an
  657.    encoded character, a URL may be made safer simply by encoding any
  658.    characters considered unsafe, while leaving already encoded
  659.    characters still encoded.
  660.    
  661.    (Note: If a new naming scheme is introduced which encodes binary
  662.    data as opposed to text, then a more compact encoding such as pure
  663.    hex or base 64 would be more appropriate.)
  664.    
  665.    The same considerations apply to mapping local fragment identifiers
  666.    onto the fragmentid part of a URL.
  667.    
  668. Specific Schemes
  669.  
  670.    The mapping for some existing standard and experimental protocols
  671.    is outlined in the BNF syntax definition.  Notes on particular
  672.    protocols follow.
  673.    
  674.   HTTP
  675.   
  676.    The HTTP protocol specifies that the path is handled transparently
  677.    by those who handle URLs, except for the servers which de-reference
  678.    them.   The path is passed by the client to the server with any
  679.    request, but is not otherwise understood by the client.  The
  680.    fragmentid part is not sent with the request.  The search part, if
  681.    present, is sent. Spaces in URLs should be escaped for transmission
  682.    in HTTP.
  683.    
  684.   FTP
  685.   
  686.    The ftp: prefix indicates a file which is to be picked up from the
  687.    file system of the given host. The FTP protocol is used. The port
  688.    number if given gives the port of the FTP server if not the FTP
  689.    default. (A client may in practice use local file access to
  690.    retrieve objects which are available though more efficient means
  691.    such as local file open or NFS mounting, where this is available
  692.    and equivalent).
  693.  
  694.  
  695. Berners-Lee                                                          12
  696.  
  697. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  698.  
  699.    
  700.     The syntax allows for the inclusion of a user name and even a
  701.    password for those systems which do not use the anonymous FTP
  702.    convention. The default, however, if no user or password is
  703.    supplied, will be to use that convention, viz. that the user name
  704.    is "anonymous" and the password the user's mail address.
  705.    
  706.    The adoption of a unix-style syntax involves the conversion into
  707.    non-unix local forms by either the client or server. Some non-unix
  708.    servers do this, but clients wishing to access sites which do not
  709.    have unix-style naming will need certain algorithms to enable
  710.    other file systems to be identified and treated.  Client software
  711.    may also have to be flexible in terms of the sequence of FTP
  712.    commands used with different varieties of server.  In view of a
  713.    tendency for file systems to look increasingly similar, it was felt
  714.    that the URL convention should not be weighed down by extra
  715.    mechanisms for identifying these cases.
  716.    
  717.    The data format of a file can only, in the general FTP case, be
  718.    deduced from the name, normally the suffix of the name. This is not
  719.    standardized. An alternative is for it to be transferred in
  720.    information outside the URL. The transfer mode (binary or text)
  721.    must in turn be deduced from the data format.  It is recommended
  722.    that conventions for suffixes of public archives be established,
  723.    but it outside the scope of this paper.
  724.    
  725.   NEWS
  726.   
  727.    The news locators refer to either news group names or article
  728.    message identifiers which must conform to the rules of RFC 850.  A
  729.    message identifier may be distinguished from a news group name by
  730.    the presence of the commercial at "@" character. These rules imply
  731.    that within an article, a reference to a news group or to another
  732.    article will be a valid URL (in the partial form).
  733.    
  734.    A news URL may be dereferenced using NNTP or using any other
  735.    protocol for the conveyance of usenet news articles.
  736.    
  737.     Note1:
  738.     
  739.    Among URLs the news: URLs are anomalous in that they are
  740.    location-independent. They are unsuitable as URN candidates because
  741.    the NNTP architecture relies on the expiry of articles and
  742.    therefore a small number of articles being available at any time.
  743.    When a news: URL is quoted, the assumption is that the reader will
  744.    fetch the article or group from his or her local news host.  News
  745.    host names are NOT part of news URLs.
  746.    
  747.     Note 2:
  748.     
  749.    An outstanding problem is that the message identifier is
  750.    insufficient to allow the retrieval of an expired article, as no
  751.  
  752.  
  753. Berners-Lee                                                          13
  754.  
  755. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  756.  
  757.    algorithm exists for deriving an archive site and file name. The
  758.    addition of the date and news group set to the article's URL would
  759.    allow this if a directory existed of archive sites by news group.
  760.    Suggested subject of study in conjunction with NNTP WG.  Further
  761.    extension possible may be to allow the naming of subject threads as
  762.    addressable objects.
  763.    
  764.   NNTP
  765.   
  766.    This is an alternative form of reference for news articles,
  767.    specifically to be used with NNTP servers, and particularly those
  768.    incomplete server implementations which do not allow retrieval by
  769.    message identifier.
  770.    
  771.    The news server name, newsgroup name, and index number of an
  772.    article within the newsgroup on that particular server are given.
  773.    
  774.     Note1.
  775.     
  776.    This form of URL is not of global accessiablity, as typically NNTP
  777.    servers only allow access from local clients.  This form or URL
  778.    should not be quoted outside this local area.  It should not be
  779.    used within news articles for wider circulation than the one
  780.    server.
  781.    
  782.   WAIS
  783.   
  784.    The current WAIS implementation public domain requires that a
  785.    client know the "type" and length of a object prior to retrieval.
  786.    These values are returned along with the internal object identifier
  787.    in the search response. They have been encoded into the path part
  788.    of the URL in order to make the URL sufficient for the retrieval of
  789.    the object.  If  changes to WAIS specifications make the internal
  790.    id something which is sufficient for later retrieval then this will
  791.    not be necessary.  Within the WAIS world, names do not of course
  792.    not need to be prefixed by "wais:"  (by the partial form rules).
  793.    
  794.    The length not now being strictly necessary is kept for historical
  795.    reasons.
  796.    
  797.   PROSPERO
  798.   
  799.    The Prospero (Neuman, 1991) directory service is used to resolve
  800.    the URL yielding an access method for the object (which can then
  801.    itself be represented as a URL if translated). The host part
  802.    contains a host name or internet address.  The port part is
  803.    optional.  The path part contains a host specific object name, an
  804.    optional version number, and an optional list of attributes.  If
  805.    these latter fields are present thy are separated from the host
  806.    specific object name and from each other by the characters "%00"
  807.    (percent, zero, zero),  this being and escaped string terminator
  808.    (null).  If the optional list of attributes is provided, the
  809.  
  810.  
  811. Berners-Lee                                                          14
  812.  
  813. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  814.  
  815.    version number must be present, but may be the empty string (i.e.
  816.    the first attribute would be separated from the host specific name
  817.    by "%00%00"). External Prospero links are represented directly as
  818.    URLs of the underlying access method and are not represented as
  819.    Prospero URLs.
  820.    
  821.   GOPHER
  822.   
  823.    The first character of the URL path part (after the initial single
  824.    slash) is a single-character "type" field which is that used by the
  825.    Gopher protocol.  The rest of the path is the "selector string",
  826.    with disallowed characters encoded. Note that some selector strings
  827.    begin with a copy of the gopher type character, in which case that
  828.    character will occur twice consecutively in the URL. If the type
  829.    character and selector are omitted, the type defaults to "1".
  830.    Gopher links which refer to non-Gopher protocols are represented
  831.    directly as URLs of the underlying access method and are not
  832.    represented as Gopher URLs.
  833.    
  834.   MAILTO
  835.   
  836.    This allows a URL to specify an RFC822 addr-spec mail address.
  837.    Note that use of % , for example as used in forming a gatewayed
  838.    mail address, requires conversion to %25 in a URL.
  839.    
  840.    This semantics may be considered to be that the object referred to
  841.    by the mailto: URL is the set of messages sent to or from that
  842.    address. There is no algorithm to retrieve this set, but the SMTP
  843.    protocol allows messages to be added to it, and any given user may
  844.    be aware of a subset of its members.
  845.    
  846.   TELNET, RLOGIN, TN3270
  847.   
  848.    The use of URLs to represent interactive sessions is a convenient
  849.    extension to their uses for objects.  This allows access to
  850.    information systems which only provide an interactive service, and
  851.    no information server. As information within the service cannot be
  852.    addressed individually or, in general, automatically retrieved,
  853.    this is a less desirable, though currently common, solution.
  854.    
  855.   X500
  856.   
  857.    The mapping of x500 names onto URLs is not defined here. A decision
  858.    is required as to whether "distinguished names" or "user friendly
  859.    names" (ufn), or both, should be allowed. If any punctuation
  860.    conversions are needed from the adopted x500 representation (such
  861.    as the use of slashes between parts of a ufn) they must be defined.
  862.    This is a subject for study.
  863.    
  864.   WHOIS
  865.   
  866.    This prefix describes the access using the "whois++" scheme in the
  867.  
  868.  
  869. Berners-Lee                                                          15
  870.  
  871. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  872.  
  873.    process of definition. The host name part is the same as for other
  874.    IP based schemes. The path part can be either a whois handle for a
  875.    whois object, or it can be a valid whois query string. This is a
  876.    subject for further study.
  877.    
  878.   NETWORK MANAGEMENT DATABASE
  879.   
  880.    This is a subject for study.
  881.    
  882.   REGISTRATION OF NAMING SCHEMES
  883.   
  884.    A new naming scheme may be introduced by defining a mapping onto a
  885.    conforming URL syntax, using a new scheme identifier. Experimental
  886.    scheme identifiers may be used by mutual agreement between parties,
  887.    and must start with the characters "x-".  The scheme name "urn:" is
  888.    reserved for the work in progress on a scheme for more persistent
  889.    names.  Therefore URNs (Names) and URLs (Locators)  be
  890.    distinguishable. An object which is either a URL or a URN is known
  891.    as a URI (Identifier).
  892.    
  893.    It is proposed that the Internet Assigned Numbers Authority (IANA)
  894.    perform the function of registration of new schemes. Any submission
  895.    of a new URI scheme must include a definition of an algorithm for
  896.    the retrieval of any object within that scheme. The algorithm must
  897.    take  the URI and produce either a set of URL(s) which will lead to
  898.    the desired object, or the object itself, in a well-defined or
  899.    determinable format.
  900.    
  901.    It is recommended that those proposing a new scheme demonstrate its
  902.    utility and operability by the provision of a gateway which will
  903.    provide images of objects in the new scheme for clients using an
  904.    existing protocol. If the new scheme is not a locator scheme, then
  905.    the properties of names in the new space should be clearly defined.
  906.     It is likewise recommended that, where a protocol allows for
  907.    retrieval by URI, that the client software have provision for being
  908.    configured to use specific gateway locators for indirect access
  909.    through new naming schemes.
  910.    
  911. BNF syntax
  912.  
  913.    This is a BNF-like description of the Uniform Resource Locator
  914.    syntax. A vertical  line "|"  indicates alternatives, and
  915.    [brackets]  indicate optional parts.  Spaces are representated by
  916.    the word "space", and the vertical line character by "vline".
  917.    Single letters stand for single letters. All words of more than one
  918.    letter below are entities described somewhere in this description.
  919.    
  920.    The "generic" production gives a higher level parsing of the same
  921.    URLs as the other productions.  The "national" and "punctuation"
  922.    characters fo not appear in any productions and therefore may not
  923.    appear in URLs.
  924.    
  925.  
  926.  
  927. Berners-Lee                                                          16
  928.  
  929. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  930.  
  931.    The "afsaddress" is left in as historical note, but is not a url
  932.    production
  933.    
  934.   fragmentaddress         uri [ # fragmentid ]
  935.                          
  936.   uri                     url
  937.                          
  938.   ur l                    generic | httpaddress | ftpaddress |
  939.                          newsaddress | nntpaddress | prosperoaddress |
  940.                          telnetaddress  | gopheraddress | waisaddress
  941.                          | mailtoaddress
  942.                          
  943.   generic                 scheme :  path [ ? search ]
  944.                          
  945.   scheme                  ialpha
  946.                          
  947.   httpaddress             h t t p :   / / hostport [  / path ] [ ?
  948.                          search ]
  949.                          
  950.   ftpaddress              f t p : / / login / path
  951.                          
  952.   afsaddress              a f s : / / cellname / path
  953.                          
  954.   newsaddress             n e w s : groupart
  955.                          
  956.   nntpaddress            n n t p : group /  digits
  957.                          
  958.   mailtoaddress           m a i l t o : : xalphas @ hostname
  959.                          
  960.   waisaddress             waisindex | waisdoc
  961.                          
  962.   waisindex               w a i s : / / hostport / database [ ? search
  963.                          ]
  964.                          
  965.   waisdoc                 w a i s : / / hostport / database / wtype  /
  966.                          path
  967.                          
  968.   groupart                * | group | article
  969.                          
  970.   group                   ialpha [ . group ]
  971.                          
  972.   article                 xalphas @ host
  973.                          
  974.   database                xalphas
  975.                          
  976.   wtype                   xalphas
  977.                          
  978.   prosperoaddress         prosperolink
  979.                          
  980.   prosperolink            p r o s p e r o : / / hostport / hsoname [ %
  981.                           0 0 version [ attributes ] ]
  982.                          
  983.   hsoname                 path
  984.  
  985. Berners-Lee                                                          17
  986.  
  987. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  988.  
  989.                          
  990.   version                 digits
  991.                          
  992.   attributes              attribute [ attributes ]
  993.                          
  994.   attribute               alphanums
  995.                          
  996.   telnetaddress           t e l n e t : / / login
  997.                          
  998.   gopheraddress           g o p h e r : / / hostport [/ gtype  [
  999.                          selector ] ] [ ? search ]
  1000.                          
  1001.   login                   [ user [ : password ] @ ] hostport
  1002.                          
  1003.   hostport                host [ : port ]
  1004.                          
  1005.   host                    hostname | hostnumber
  1006.                          
  1007.   cellname                hostname
  1008.                          
  1009.   hostname                ialpha [  .  hostname ]
  1010.                          
  1011.   hostnumber              digits . digits . digits . digits
  1012.                          
  1013.   port                    digits
  1014.                          
  1015.   selector                path
  1016.                          
  1017.   path                    void |  xpalphas  [  / path ]
  1018.                          
  1019.   search                  xalphas [ + search ]
  1020.                          
  1021.   user                    xalphas
  1022.                          
  1023.   password                xalphas
  1024.                          
  1025.   fragmentid              xalphas
  1026.                          
  1027.   gtype                   xalpha
  1028.                          
  1029.   xalpha                  alpha | digit | safe | extra | escape
  1030.                          
  1031.   xalphas                 xalpha [ xalphas ]
  1032.                          
  1033.   xpalpha                 xalpha | +
  1034.                          
  1035.   xpalphas                xpalpha [ xpalpha ]
  1036.                          
  1037.   ialpha                  alpha [ xalphas ]
  1038.                          
  1039.   alpha                   a | b | c | d | e | f | g | h | i | j | k |
  1040.                          l | m | n | o  | p | q | r | s | t | u | v |
  1041.  
  1042.  
  1043. Berners-Lee                                                          18
  1044.  
  1045. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  1046.  
  1047.                          w | x | y | z | A | B | C  | D | E | F | G |
  1048.                          H | I | J | K | L | M | N | O | P |  Q | R |
  1049.                          S | T | U | V | W | X | Y | Z
  1050.                          
  1051.                           0 |1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
  1052.                          
  1053.   safe                    $ | - | _ | @ | . | &
  1054.                          
  1055.   extra                   ! | * | " |  ' | ( | ) | : | ; | , | space
  1056.                          
  1057.   escape                  % hex hex
  1058.                          
  1059.   hex                     digit | a | b | c | d | e | f | A | B | C |
  1060.                          D | E | F
  1061.                          
  1062.   national                { | } | vline | [ | ] | \ | ^ | ~
  1063.                          
  1064.   punctuation             < | >
  1065.                          
  1066.   digits                  digit [ digits ]
  1067.                          
  1068.   alphanum                alpha | digit
  1069.                          
  1070.   alphanums               alphanum [ alphanums ]
  1071.                          
  1072.   void
  1073.                          
  1074. Wrappers for URIs in plain text
  1075.  
  1076.    This section does not formally form part of the URL specification.
  1077.    
  1078.    URIs, including URLs, will ideally be transmitted though protocols
  1079.    which accept them and data formats which define a context for them.
  1080.     However, in practice nowadays there are many occasions when URLs
  1081.    are included in plain ASCII non-marked-up text such as electronic
  1082.    mail and usenet news messages.
  1083.    
  1084.    In this case, it is convenient to have a separate wrapper syntax to
  1085.    define delimiters which will enable the human or automated reader
  1086.    to recognize that the URI is a URI.
  1087.    
  1088.    The recommendation is that the angle brackets (less than and
  1089.    greater than signs) of the ASCII set be used for this purpose.
  1090.    
  1091.    These wrappers do not form part of the URL, are not mandatory, and
  1092.    should not be used in contexts (such as SGML parameters, HTTP
  1093.    requests, etc) in which delimiters are already specified.
  1094.    
  1095.     Example
  1096.     
  1097.                 Yes, Jim, I found it under <ftp://info.cern.ch/pub> bu
  1098. t
  1099.  
  1100.  
  1101. Berners-Lee                                                          19
  1102.  
  1103. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  1104.  
  1105.                 you can probably pick it up from <ftp://ds.internic.ne
  1106. t/rfc>.
  1107.  
  1108.  
  1109. Security considerations
  1110.  
  1111.    The URL scheme does not in itself pose a security threat. Users
  1112.    should beware that there is no general guarantee that a URL which
  1113.    at one time points to a given object continues to do so, and does
  1114.    not even at some later time point to a different object due to the
  1115.    movement of objects on servers.
  1116.    
  1117.    The use of URLs containing passwords is clearly unwise.
  1118.    
  1119. Conclusion
  1120.  
  1121.    A need has been demonstrated, and a number of requirements have
  1122.    been stated for uniform resource locators (URLs). A scheme has been
  1123.    proposed which builds on existing conventions to define a syntax
  1124.    for URLs.  This scheme has been in serious use by World-Wide Web
  1125.    (W3) initiative since 1991.  Adoption of the scheme in
  1126.    correspondence, standards and software will ease the use of
  1127.    references to on-line information in a flexible way as the coming
  1128.    information age arrives.
  1129.    
  1130. Acknowledgements
  1131.  
  1132.    This paper builds on the basic W3 design and much discussion of
  1133.    these issues by many people on the network. The discussion was
  1134.    particularly stimulated by articles by Clifford Lynch (1991),
  1135.    Brewster Kahle (1991) and Wengyik Yeong (1991b). Contributions from
  1136.    John Curran (NEARnet), Clifford Neuman (ISI) Ed Vielmetti (MSEN)
  1137.    and later the IETF URL BOF and URI working group have been
  1138.    incorporated into this issue of this paper.
  1139.    
  1140.    The draft url4  (Internet Draft 00) was generated from url3
  1141.    following discussion and overall approval of the URL working group
  1142.    on 29 March 1993. The paper url3 had been generated from udi2 in
  1143.    the light of discussion at the UDI BOF meeting at the Boston IETF
  1144.    in July 1992. Draft url4 was Internet Draft 00. Draft url5
  1145.    incorporated changes suggested by Clifford Neuman, and draft url6
  1146.    (ID 01) incorporated character group changes and a few other fixes
  1147.    defined by the IETF URI WG in submitting it as a proposed standard.
  1148.     URL7 (Internet Draft 02) incorporated changes introduced at the
  1149.    Amsterdam IETF and refined in net discussion.
  1150.    
  1151. References
  1152.  
  1153.   Alberti, R., et.al.  (1991)
  1154.                           "Notes on the Internet Gopher  Protocol"
  1155.                          University of Minnesota, December 1991,
  1156.                          <ftp://boombox.micro.umn.edu/pub/gopher/
  1157.  
  1158.  
  1159. Berners-Lee                                                          20
  1160.  
  1161. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  1162.  
  1163.                          gopher_protocol> . See also
  1164.                          <gopher://gopher.micro.umn.edu/00/Information
  1165.                          About Gopher/About Gopher>
  1166.                          
  1167.   Berners-Lee, T ., (1991)
  1168.                           "Hypertext Transfer Protocol (HTTP)" , CERN,
  1169.                          December 1991,
  1170.                          <ftp://info.cer
  1171.                          n.ch/pub/www/doc/http-spec.txt>
  1172.                          
  1173.   Crocker                "Standard for ARPA Internet Text Messages".
  1174.                          David H. Crocker, RFC822,
  1175.                          
  1176.   Davis, F, et  al., (1990)
  1177.                           "WAIS Interface Protocol: Prototype
  1178.                          Functional Specification", Thinking Machines
  1179.                          Corporation,  April 23, 1990
  1180.                          <ftp://quake.think.com/pub/wa
  1181.                          is/doc/protspec.txt>
  1182.                          
  1183.   International Standards Organization, (1991)
  1184.                           Information and  Documentation - Search and
  1185.                          Retrieve Application Protocol  Specification
  1186.                          for open Systems Interconnection, ISO-10163
  1187.                          
  1188.   Huitema, C., (1991)     "Naming: strategies and techniques",
  1189.                          Computer Networks and ISDN Systems 23 (1991)
  1190.                          107-110.
  1191.                          
  1192.   Kahle, Brewster, (1991)
  1193.                          "Document Identifiers,  or  International
  1194.                          Standard Book Numbers for the Electronic
  1195.                          Age",
  1196.                          <ftp:
  1197.                          //quake.think.com/pub/wais/doc/doc-ids.txt>
  1198.                          
  1199.   Kantor, B., and Lapsley, P., (1986)
  1200.                          "A proposed standard for  the stream-based
  1201.                          transmission of news", Internet RFC-977,
  1202.                          February 1986.
  1203.                          <ftp://ds.internic.net/rfc/rfc977.txt>
  1204.                          
  1205.   Lynch, C., Coallition for Networked Information: (1991)
  1206.                          "Workshop on ID and Reference Structures for
  1207.                          Networked Information", November 1991. See
  1208.                          <wais://quake.think.com/wais-discussion-ar
  1209.                          chives?lynch>
  1210.                          
  1211.   Mockapetris, P., (1987)
  1212.                           "Domain names + concepts and  facilities",
  1213.                          RFC-1034, USC-ISI, November 1987,
  1214.                          <ftp://ds.internic.net/rfc/rfc1034.txt>
  1215.  
  1216.  
  1217. Berners-Lee                                                          21
  1218.  
  1219. RFC XXXX           Uniform Resource Locators (URL)        October 1993
  1220.  
  1221.                          
  1222.   Neuman, B. Clifford, (1992)
  1223.                           "Prospero: A Tool for Organizing  Internet
  1224.                          Resources", Electronic Networking: Research,
  1225.                          Applications and Policy, Vol 1 No 2, Meckler
  1226.                          Westport CT  USA.  See also
  1227.                          <ftp://prospero.isi.edu/pub/prospero/oir.ps>
  1228.                          
  1229.   Postel, J. and Reynolds, J. (1985)
  1230.                          "File Transfer Protocol  (FTP)", Internet
  1231.                          RFC-959, October 1985.
  1232.                          <ftp://ds.internic.net/rfc/rfc959.txt>
  1233.                          
  1234.   Yeong, W., (1991a)      "Towards Networked Information Retrieval",
  1235.                          Technical report 91-06-25-01, June 1991,
  1236.                          Performance Systems International, Inc.
  1237.                          <ftp://uu.psi.com/wp/nir.txt>
  1238.                          
  1239.   Yeong, W., (1991b),     "Representing Public Archives in the
  1240.                          Directory", Internet Draft, November 1991,
  1241.                          now expired.
  1242.                          
  1243.   AUTHOR'S ADDRESS
  1244.   
  1245.  
  1246.                            Tim Berners-Lee
  1247.                 Address:   World-Wide Web project
  1248.                            CERN,
  1249.                            1211 Geneva 23,
  1250.                            Switzerland
  1251.  
  1252.                 Telephone: +41 (22)767 3755
  1253.                 Fax:       +41 (22)767 7155
  1254.                 Email:     timbl@info.cern.ch
  1255.  
  1256.  
  1257.  
  1258.  
  1259.    
  1260.  
  1261.  
  1262.  
  1263.  
  1264.  
  1265.  
  1266.  
  1267.  
  1268.  
  1269.  
  1270.  
  1271.  
  1272.  
  1273.  
  1274.  
  1275. Berners-Lee                                                          22
  1276.  
  1277.